Skip to content

Conversation

staticlibs
Copy link

This change makes all CMake targets to use -MT/-MTd compilation flags for Windows MSVC builds. This way the MSVC runtime library is linked statically and the workaround for VS2019 described in duckdb/duckdb#17991 is no longer necessary.

extension-ci-tools PR: duckdb/extension-ci-tools#276

Ref: duckdblabs/duckdb-internal#2036

This change makes all CMake targets to use `-MT`/`-MTd` compilation
flags for Windows MSVC builds. This way the MSVC runtime library is
linked statically and the workaround for VS2019 described in
duckdb/duckdb#17991 is no longer necessary.

`extension-ci-tools` PR: duckdb/extension-ci-tools#276

Ref: duckdblabs/duckdb-internal#2036
@staticlibs staticlibs marked this pull request as draft October 17, 2025 17:24
@staticlibs
Copy link
Author

The Python build setup is complex, it is not clear that this CMake flag covers everything. @evertlammerts
please take a look at your convenience.

The PR is only intended to be merged after the extension-ci-tools PR linked above it merged, so moving it to draft.

@paultiq
Copy link
Contributor

paultiq commented Oct 18, 2025

There's a nuanced discussion of statically linking c++ extensions here, the key point is ensuring the UCRT remains dynamically linked, which I don't see in this PR: https://discuss.python.org/t/planning-for-an-msvc-abi-break/65102/21

See Matplotlib, a static c++ runtime but dynamic ucrt: https://github.com/matplotlib/matplotlib/pull/28687/files

@staticlibs
Copy link
Author

@paultiq

Thanks for the pointers! Just currently there are no plans to have VCRUNTIME or UCRT libs to be linked dynamically, unless that would be a blocker for the Python client. In general we don't want any complex linking setup around MSVC runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants